IBIS Macromodel Task Group

Meeting date: 29 September 2020

Members (asterisk for those attending):
Achronix Semiconductor      * Hansel Dsilva
ANSYS:                      * Curtis Clark
                            * Wei-hsing Huang
Cadence Design Systems:     * Ambrish Varma
                              Ken Willis
                              Jared James
Google:                       Zhiping Yang
Intel:                      * Michael Mirmak
                              Kinger Cai
Keysight Technologies:      * Fangyi Rao
                              Radek Biernacki
                              Ming Yan
                              Todd Bermensolo
                            * Rui Yang
Marvell                       Steve Parker
Mentor, A Siemens Business: * Arpad Muranyi
Micron Technology:          * Randy Wolff
                            * Justin Butterfield
SiSoft (Mathworks):           Walter Katz
                              Mike LaBonte
Teraspeed Labs:             * Bob Ross
Zuken USA:                    Lance Wang

The meeting was led by Arpad Muranyi.  Curtis Clark took the minutes.

--------------------------------------------------------------------------------
Opens:

- None.

-------------
Review of ARs:

- Michael to send a third draft of the [Clock Pins] BIRD proposal.
  - Done.
  
--------------------------
Call for patent disclosure:

- None.

-------------------------
Review of Meeting Minutes:

Arpad asked for any comments or corrections to the minutes of the September 22
meeting.  Bob noted that his comments with respect to a "rail specification"
should have been recorded as RAIL (Rules Augmented Interconnect Layout)
specification.  Since the minutes had not yet been uploaded to the ATM minutes
page on the IBIS website, Curtis took an AR to send out an amended version.
Randy moved to approve the amended minutes.  Ambrish seconded the motion.  There
were no objections.

-------------
New Discussion:

Topic Bin List:
Arpad noted that he had removed the "IBIS-ISS parser" entry in the topic bin
list, as Randy had earlier suggested.  This topic has been taken up by the
Interconnect task group.

New Clock-Data Pin relationship BIRD [Clock Pins]:
Michael Mirmak briefly summarized the third draft of the [Clock Pins] BIRD,
which he had sent out prior to the meeting.  Based on concerns expressed about
not fully defining the timing relationship entries in column 3, he had removed
column 3 altogether.  There are now two columns.  The first column must contain
a clock pin, and the second column contains a data or clock pin.  This draft no
longer mentions the possibility of a third column.

Ambrish noted that the second column could contain a data or clock pin, but he
observed that the second column Sub-Param was called "data_pins".  Michael
agreed that this was an inconsistency and asked for other suggestions for the
name.  Ambrish suggested "clocked_pins".  Michael agreed with this suggestion,
and no one objected.

Bob said he would prefer that we kept the third column and its placeholder
values if we ever have any intention of adding it later.  He said adding new
columns to the keyword later gets messy.  If we don't have the third column
now, then this keyword should be limited to stating a relationship between two
pins, and we should not plan on extending it later.  Ambrish asked if Bob
considered the BIRD incomplete with only two columns.  Bob said he did consider
it incomplete if we had a BIRD with the expectation of having to add more
columns to the keyword later.  Bob said that if we really get into timing
relationships it gets complicated quickly.  The RAIL specification, for example,
had gone into all sorts of combinations of rising edge, falling edge, etc.  This
would likely be too much to include with this keyword, so the third column
could ultimately just point to a new keyword (new BIRD) that would be needed to
define the timing relationships.  Bob preferred that we keep a third column with
some defined value(s) that we knew would be useful later.

Michael reiterated that his primary goal was to capture the clock pin to data
pin relationship envisioned by recent BIRDs like BIRD204 and BIRD207.  However,
there is more information that will ultimately be needed.  He said the third
column could provide information analogous to Vinl and Vinh, for example.  You
need to give the user/tool enough information to know if their timing is outside
of design requirements.  His fear was that it would be a long arduous process to
iron out the details of any definitions in column 3, but if we didn't have this
BIRD at all then we may end up with no easy way to add the basic relationship
information later.

Michael noted that Arpad had asked for more information on the values in column
3 at the previous meeting.  He asked Arpad if he preferred two columns or three.
Arpad asked if there was really much of a difference between two columns and
three columns if the third column contained a non-functional placeholder.  Bob
said there were parser implications and forward-compatibility complications with
adding a column later.

Ambrish asked if we could populate the third column with "placeholder" or some
other string to avoid the confusion of attempting to specify more meaningful
names at this point.  Michael said that it might be strange to draft a proposal
with a third column that is essentially for future expansion, but he was okay
with it.  He said he thought that the third column might eventually refer to a
new keyword, or perhaps to a file, containing the additional information.  The
group discussed several possible placeholder values.  NA (not applicable) was
seen as confusing.  Michael suggested the string "unspecified".  No one
objected.  Bob noted that this would be a case-sensitive string comparison, as
it is not a reserved word or keyword.

Bob suggested a careful review of the language associated with Series models.
He noted language regarding "prohibited Model_types" Series, Series_switch,
and Terminator and another section stating [Clock Pins] is "not compatible"
with [Series Switch Groups] or [Series Pin Mapping].  He said we may need to
explicitly state that certain combinations are illegal.

Bob said the proposal's language, which excluded pins appearing in column 2 from
appearing on more than one line, was blocking a legal configuration such as a
clock tree made up of I/O elements in which the clock-data relationship between
two pins could go in either direction.  Arpad asked if the question from Bob and
Fangyi the previous week about a pin appearing as the clock pin on one line and
the data pin on another had been resolved.  Michael referred to this sentence in
Usage Rules:
  Entries in the second column shall not appear on more than one line under the
  keyword.
He said it prohibited all of these scenarios.  However, he removed the rule in
order to relax the restriction.  He said the rule was compatible with DDR
applications, but removing it opens up the possibility of supporting other
topologies like Bob had described.  He said removing the rule made it impossible
for the parser to catch some illegal combinations in the DDR context unless we
were to add additional rules for each specific application.

Michael gave himself an AR to create a fourth draft of the BIRD with these
changes from the meeting discussion:
 - Add a third column with "unspecified" as the entries.
 - Remove the restriction on entries in the second column appearing on other
   lines.
 - Address additional editorial comments Bob would send to him.

- Curtis: Motion to adjourn.
- Randy: Second.
- Arpad: Thank you all for joining.

AR: Curtis to send amended minutes from the previous meeting.
AR: Michael to create a fourth draft of the [Clock Pins] BIRD proposal.

-------------
Next meeting: 06 October 2020 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives
